TCP-Group Digest Fri, 14 Sep 90 Volume 90 : Issue 138 Today's Topics: Anyone driving to the ARRL C.N.C from the Bay Area? Anyone driving to the ARRL C.N.C from the Bay Area? (fwd) Ethernet <$100 failures hp9000/800 NET net write through screen bios? NOS 900828 failure (3 msgs) rspf status RSPF Trials on LI not going well Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". ---------------------------------------------------------------------- Date: Thu, 13 Sep 90 8:25:07 EDT From: (null) Subject: Anyone driving to the ARRL C.N.C from the Bay Area? To: tcp-group@ucsd.edu My roomy has a small quantity of telephone parts waiting for him in San Francisco. Is anyone from that area planning to drive to the C.N.C. next weekend, and would they be willing to pick up said junk and bring it to the C.N.C.? -- ----------------- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs -- ----------------- Marcus Leech, 4Y11 Bell-Northern Research |opinions expressed mleech@bnr.ca P.O. Box 3511, Stn. C |are my own, and not VE3MDL@VE3JF.ON.CAN.NA Ottawa, ON, CANADA |necessarily BNRs ------------------------------ Date: Thu, 13 Sep 90 08:26:00 EDT From: Marcus (M.D.) Leech Subject: Anyone driving to the ARRL C.N.C from the Bay Area? (fwd) To: tcp-group@ucsd.edu Forwarded message: ------------------------------ Date: Thu, 13 Sep 90 12:34:05 EDT From: jbloom@uhasun.hartford.edu (Jon Bloom) Subject: Ethernet <$100 To: tcp-group@ucsd.edu In the search for low-cost networking, I've stumbled across an 8-bit Ethernet card for $99. Since I haven't seen anything cheaper (let me know if you have!) I thought I'd pass it along. The board is advertised as an NE1000 "equivalent," and it works just fine with the latest Clarkson NE1000 driver. We bought a pair of the boards from: MCW Distribution, 800-638-9118 (Maryland). They also advertise an NE2000 (16-bit) equivalent which I have not tried. Ethernet is getting _cheap_! Jon ------------------------------ Date: Thu, 13 Sep 90 16:51:56 EDT From: crompton@NADC.NADC.NAVY.MIL (D. Crompton) Subject: failures To: tcp-group@ucsd.edu I (and our local group) have found the late (since about May) versions of NOS (G1EMM) to be very stable. We run it on a real mixture of machines and machine enviroments. I have never seen a garbage collection message from NOS nor after weeks of operation do I see any "Yellow" or "red" alerts. For the most part we give NOS either full memory or a full DOS window in DV. This would be around 510-580K of startup memory. I have watched the Stack status (ps) and I have never found a stack to be more than 50% of maximum. Even before the timer stack change. My particuliar system is a V20 8MHZ with four 16550a's running nrs/kiss ports. No ethernet. The addition of 'rspf' in G1EMM has been the only recent blip. It seems to cause problems when it is turned on but not when it is off. I handle a fairly heavy load of smtp and ftp on this system. This is not to say that there are not some real problems that are being experienced but it must be related to something (WHAT?) that is being done differently than we are doing it. Since NOS uses alot or most of memory in some cases maybe this really exercises the machine and it is pointing to a flakey machine or memory that ordinarilly would not show up? Doug ------------------------------ Date: Thu, 13 Sep 90 10:16:51 mdt From: Bdale Garbee Subject: hp9000/800 NET To: tcp-group@ucsd.edu Several people have asked me over time how to get NET running on an HP-PA system. I just received an account with considerable detail from someone who has made the 890421.1 version work fine on a 9000/840. If anyone needs the details, email me and I'll forward them out. It's a largish hunk of text, so I won't post it here. Bdale, bdale@col.hp.com ------------------------------ Date: Thu, 13 Sep 90 17:28:13 EDT From: foxworth@bnlls1.nsls.bnl.gov (Bob Foxworth) Subject: net write through screen bios? To: tcp-group@ucsd.edu The following message appeared on the local AX25 networks on LI about a week ago, and I am passing it on here. Text follows: (rest of headers deleted) R:900906/1615Z @:N2EYR [N.Y.C.,NY] F:441.00/145.030 #:11625 Z:10032 can anyone tell me if the tcpip program can write through the screen bios? I need to know this because I am a sightless ham and my speech synthesizer will not scroll properly if the software won't write through bios. I appreciate any feedback from tcpip users on this point. this will enable me to decide whether or not to get the program. thanks for your help. 73 dan n2fwq @ n2eyr.ny.usa.na [end forwarded message] ANy replies that may be posted here, pls indicate if they were also sent direct to Dan. Pls reply direct to him if you are able. I do not know this fellow, but thought this is a good medium to help him. 73 Bob ------------------------------ Date: Thu, 13 Sep 90 15:39 GMT From: Subject: NOS 900828 failure To: tcp-group@ucsd.edu Aha! I'm so glad that someone has reported this! This looks very similar to one of the ways in which NOS has been crashing off and on for me for the past several months. I would ask you which compiler you used to recompile NOS; I find that TC++ produces that warning message in a seemingly spurious manner quite frequently. Every time I report this type of problem other people come on and tell me how wonderfully stable NOS is at their location. I've just been sitting back waiting for someone else to get bit; I figured it would happen sooner or later. BTW, I tried different hardware, TNC and versions of NOS. Seems to make no difference here. Every now and then it will crash the way you said. Similarly, I am convinced that there is a problem in the NETROM code because that causes me crashes sometimes too (although I'm really confused about that because testing it out with different people around here produce reproducible problems on different people's systems -- but the problems are different on different systems!). Onward and upward... 73 -- Doc ------------------------------ Date: Thu, 13 Sep 90 10:57:51 MST From: dlf@phx.mcd.mot.com (Dave Fritsche) Subject: NOS 900828 failure To: tcp-group@ucsd.edu (tcp-group) > Aha! I'm so glad that someone has reported this! This looks very similar > to one of the ways in which NOS has been crashing off and on for me for > the past several months. I would ask you which compiler you used to > recompile NOS; I find that TC++ produces that warning message in a > seemingly spurious manner quite frequently. Forgot to mention, I used the TC 2.0 compiler (haven't ordered TC++ yet). Only thing i did was edit the config header file to "turn on" the SCC driver. I also modified version.c to change the "900828" to "900828+SCC". I like to be know what executables are no longer "stock". As soon as I power cycled the machine, and re-booted, NOS came up fine, as usual. About the time the SMTP timer kicked in for the first time (and tried to start sending the mail that had been in progress before the crash), I started getting a bunch of messages scrolling across the screen saying something I think about a stack pointer out of its valid range. This was an unending stream of messages that was scrolling as fast as they could be printed (the address in the message was decrementing I believe). I was parinoid that I may have bumped the squelch control on the Kantronics DVR2-2 radio, and had the squelch running open, and that maybe the PC-100 was causing problems. (I've found that the DVR2-2 has quite a few intermod problems in use around Pheonix here, and with potentially open squelch, I don't know what all might have been going on.) Since there's no speaker on the radio, I just tweaked the squelch control up a bit, rebooted, started NOS, and haven't had a problem in the last 12 hours. Again, until last night, I'd never experienced a problem of this sort (activity in AZ isn't the most vigorous, since there's only 2 of us that are very active with TCP/IP). 73 . . . Dave Fritsche (wb8zxu) dlf@phx.mcd.mot.com ------------------------------ Date: Thu, 13 Sep 90 18:42:09 UTC From: karn@ka9q.bellcore.com (Phil Karn) Subject: NOS 900828 failure To: DEVANS%COLOLASP.BITNET@cornellc.cit.cornell.edu, tcp-group@ucsd.edu My experience has been that spectacular crashes of this type are now almost always caused by a process that overflows its stack. Choosing stack sizes in NOS is a trial-and-error process; there doesn't seem to be a better way (if somebody can come up with one, I'd be very grateful). So the next time things start going crazy, try running the "ps" command (if the system is still capable of doing so) and look for any tasks that have exceeded their stack allocations. The stack high water marks should always be well below the stack size figures to give an adequate safety margin. Sometimes it takes a while for the system to start dying after a stack overflows, so if you can run ps regularly even when things seem OK, you might find the first evidence of a stack overflow. Phil ------------------------------ Date: Thu, 13 Sep 90 17:06:15 GMT From: kelvin@kelvin.uk22.bull.com Subject: rspf status To: tcp-group@ucsd.edu All, I have incorporated Anders fix to rspf (the route deletion problem) and have uploaded the new g1emm version to thumper. The files are emm82812.* in /pub/ka9q/incoming. I have to say however, that it still doesn't work and in fact causes severe (power-off only) system crashes when it's been running for a while. In view of this, I cannot recommend using rsfp until Fred, Anders and any other brave souls who feel like debugging the code have come up with some fixes. The symptom seems to be corrupted memory pointers leading to either a total hang or garbage pointers detected in free(). If rspf is NOT invoked the problems go away. best of luck! All the best, Kelvin. +-------------------------------------------------+ | Kelvin J.Hill - BULL HN Ltd, Hounslow, England. | | Internet - kelvin.uk22.bull.com [128.35.110.6] | | Amprnet - g1emm.ampr.org [44.131.7.6] | +-------------------------------------------------+ ------------------------------ Date: Thu, 13 Sep 90 15:49:45 EDT From: foxworth@bnlls1.nsls.bnl.gov (Bob Foxworth) Subject: RSPF Trials on LI not going well To: tcp-group@ucsd.edu Several locals tried running rspf in the central LI (NY) subnet, n2pl, wb2dvk, and a day later, k2euh and kc2ky. N2pl sent me mail via amprnet saying his routing table entries disappeared, and I believe he stopped running rspf. I am not sure of the details, not even what version of NOS Paul is running. I am using emm82811, I set the rspf parameters according to Anders' note in the 18 August tcp-digest, set preferred mode to datagram. I believe Ron, dvk had emm82810 running Tuesday night and I saw his RSPF protocol IP QST's to 44.255.255.255 and caught one QST from him as: RSPF: type Routing Update nodes 0 id 1 Reporting Router: 44.68.8.34 Seq 3 Subseq 0 links 1 horizon 32 ERP factor 0 cost 8 adjacencies 4 44.68.8.35/32 44.68.8.58/32 44.68.8.25/32 44.68.8.22/32 At that point I did a status on my system: net> rspf status Addr Cost Seq Heard Time TOS State 44.68.8.34 8 262 0 0:00:50:18 16 OK 44.68.8.41 8 0 0 0:00:45:19 0 OK 44.68.8.58 8 0 0 0:00:42:51 0 OK 44.68.8.82 8 0 0 0:00:00:00 0 Suspect 34, 41 and 58 are all active and well heard. 82 is probably a result of a manual entry in my autoexec "arp add". I probably should delete it. Note that I restarted NOS about 55 minutes before taking this data. About 5 or 7 minutes after this, my station 44.68.8.35 broadcast a reporting router update. I caught most of it to screen, but not before a couple lines scrolled off. I sent my data, then apparently rebroadcast then the report from wb2dvk (44.68.8.34) as so: (top 2 lines not copied to printer - these were my heard stations:) horizon 32 ERP factor 0 cost 8 adjacencies 3 44.68.8.58/32 44.68.8.41/32 44.68.8.34/32 Reporting Router: 44.68.8.34 Seq 3 Subseq 0 links 1 horizon 31 ERP factor 0 cost 8 adjacencies 4 44.68.8.35/32 44.68.8.58/32 44.68.8.25/32 44.68.8.22/32 At this point everything appeared to be working normally.Time 0420Z on 12 Sept. I checked next at about 2230Z that date and found no mail had arrived, NOS basically appeared to be running OK but I was unable to send a ping to anyone except kc2ky (44.68.8.58) and he was the *sole* station appearing in my net>rspf status listing. Any other station pinged would not resolve and would not even transmit. The other 2 known heards (41) (nq2d) and 34 (wb2dvk) were still up. I think dvk had discontinued rspf; nq2d I am sure has not yet tried it. I saw the reference to a bug fix a day or two ago. I believe this refers to the problem. I was running emm82811 which I ftp'ed from thumper and took home, and wb2dvk (34) and kc2ky (58) had ftp'ed it from me over the air. I know this is lengthy. I hope there is a clue for Anders or someone else in here. I know we are interested in continuing to play with it, and await further developments/versions of code. I think a brief list of what parameters to check if there appears to be a problem would help too. We have copies of the k1io documentation by the way. 73 Bob k2euh ------------------------------ End of TCP-Group Digest ******************************